The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. Similarly, whether or not a given approach is prior art, the problems identified with that approach should not be assumed to have been recognized in the prior art.
A database server stores data in one or more data containers, each container contains records, and the data within each record is organized into one or more fields. In a database system that stores data in a relational database, the data containers are referred to as tables, the records are referred to as rows, and the attributes are referred to as columns. In object oriented databases, the data containers are referred to as object classes, the records are referred to as objects, and the attributes are referred to as object attributes. Other database architectures may use other terminology.
The present invention is not limited to any particular type of data container or database architecture. However, for the purpose of explanation, the examples and the terminology used herein shall be that typically associated with relational databases. Thus, the terms “table”, “row” and “column” shall be used herein to refer respectively to the data container, record, and field.
A database server retrieves and manipulates data in response to receiving a database statement. Typically the database statement conforms to a database language, such as Structured Query Language (SQL). A database statement can specify a query operation, a data manipulation operation, or a combination thereof. A database statement that specifies a query operation is referred to herein as a query. The present invention is not limited to database statements that specify a particular type of operation. However, for the purpose of explanation, embodiments of the present invention are illustrated using queries.
One function of a database server is to control access to database data. Security mechanisms on database servers control what data may be accessed by a query issued by a user. One type of security mechanism is referred as a fine-grained access control mechanism. An example of fine-grained access control is described in U.S. Pat. No. 6,487,552, issued Nov. 26, 2002 to Chon Hei Lei et al, which is incorporated herein by reference in its entirety. Fine-grained access control may be used to grant and/or deny access to one or more rows of a table.
Despite its power and flexibility, fine-grained access control has some drawbacks. For many data access and privacy requirements, it is desirable that rows be returned in a query without the data in certain security sensitive columns. However, fine-grained access control either allows access to the entire row or does not allow access to any part of the row. An approach that may be considered to control access to columns is what shall be referred to as the “view approach”. Under the view approach, all access to a table is performed indirectly through a view. Views offer a convenient way to provide column level access control when the users fall into a relatively small number of categories based on security needs. For example, if users are categorized into two categories, then only two views need to be created. However, many access policies require users to be divided into a large number of categories based on multiple criteria. Providing views for a large number of categories may be onerous. Similarly, programming the database applications to use all these views may also be onerous. Furthermore, it is often infeasible to rewrite packaged applications to use the views.
Based on the foregoing, it is desirable to provide column level access control that avoids the pitfalls of the approaches discussed above.